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Many organizations continue to use standard operating procedures and work processes that were designed or 
evolved in previous eras and environments. The result can be long cycle times, low quality, high inventories, and a 
generally poor response to customer needs[4, 7]. Business process re-engineering is radical redesign to sirnplify 
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work and to improve service and quality. Re-engineering involves reevaluating the entire business process, 
analyzing the interrelationships among business units, and identifying changes that would eliminate redundant 
processes and create more efficient and effective units. 

The purpose of this article is to present the development and evaluation of one methodology for business process 
re-engineering. This methodology leverages information technology via Electronic Meeting Systems (EMS)[17] to 
improve the productivity of groups by providing a communication and information infrastructure, and the opportunity 
to use more structured group processes and task analysis techniques. We present here a case study in which a 
re-engineering team in a major multinational firm used an EMS-based methodology to analyze business processes 
and develop proposals for change. 

BUSINESS PROCESS RE-ENGINEERING 

Re-engineering has emerged as a means of increasing competitiveness in the 1990s, although its concepts have 
been advocated for years. In general, re-engineering starts by developing a business process model of how the 
activities currently function. This model is then examined to find new, innovative approaches to the business process 
that can produce dramatic benefits. 

The core idea behind re-engineering is to develop and implement a set of radical, revolutionary ideas that will 
drannatically improve performance. In contrast, other approaches such as total quality management (TQM) or 
continuous process improvement strive to find areas for incremental, evolutionary improvements. For example, 
suppose you operate a package delivery service in a large city whose delivery personnel use tricycles. Your 
objective is to increase the speed of delivery. Incremental improvements (prompted by TQM, for example) might 
lead to the idea of building racing tricycles with bigger wheels and a swept-back design, or the idea of equiping 
drivers with special clothing to reduce wind resistance. Radical improvements (prompted by re-engineering) might 
suggest moving from tricycles to bicycles or even roller blades. Of course, even with enthusiastic participation, it 
may not be easy to make the change, because drivers need to be retrained and may require quite a different set of 
skills. The best tricyclist may not be the best bicyclist or even a passable skater. 

Hammer[7] develops several principles for redesigning organizational work flows and standard procedures. These 
principles focus on empowering lower-level employees, distributing information collection and processing in the 
organization, and integrating information up the organizational hierarchy. Davenport and Short[4] also provide 
redesign principles, but, more importantly, provide a methodology for the overall re-engineering effort. This 
methodology involves defining business objectives, identifying processes to be redesigned, understanding existing 
processes, identifying IT levers, and building a prototype of the redesigned processes. 

As companies scramble to understand how to re-engineer, some guidance is available from the published 
descriptions of re-engineering experiencesfTJ- However, since few formal studies have been documented, we do not 
have a detailed, validated model for re-engineering. We do, however, have a reasonable understanding of the 
problem. Many current business processes were designed to fit a business environment that no longer exists[4, 7] 
Processes are legacies of scientific management[19] as practiced in the efficiency-minded 1950s: processes were 
separated into narrow "small" tasks that could be performed by less skilled workers with little responsibility or 
authonty, while decisions were made by supposedly higher-skilled, more trusted managers and professionals. The 
goal of re-engineering is to use more modern management approaches and information technology to redesign the 
business to fit today's (and tomorrow's) environment. 

Most current approaches to re-engineering are primarily "low tech" or manual processes that use sequential 
interviews or traditional verbal group meeting processes to develop the business model and identify opportunities for 
improvement. It can take months or even years for analysts to interview everyone involved with a process, validate 
the model, and finalize the process improvement data[1 , 12, 13]. And, of course, traditional group processes are 
fraught with difficulty[17]. While these approaches assist business process re-engineering teams, there is ample 
room for improvement. 

While there may be a general model for re-engineering, implementation must be customized and adapted to the 
specific needs and goals of each organization. The specific information modeled for each process, person, and 
information flow, the focus of model analysis, and the degree of prototyping new processes will vary from 
organization to organization. 

The number and variety of stakeholders associated with a process dictate the level and style of communication 
required. The organization's handling of previous change efforts will also influence the employees' expectations 
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about management's acceptance of their suggestions. Technology for efficiently recording, organizing, and 
reviewing the contributions to the project should be extremely valuable. 

THE ENTERPRISE ANALYZER APPROACH 

The Enterprise Analyzer (EA) approach assists a group in identifying high-level business processes, decomposing 
these processes, and establishing information flows among the processes and other information sources[2]. It 
builds on prior electronic meeting systems (EMS) research to improve the performance of business teams[3, 5, 17]. 
EMS are information technology-based group meeting environments that provide a networked computer 
workstation to each group member. EMS enable groups to meet face-to-face with computer-mediated electronic 
communication used to supplement or replace verbal communication and decision modeling software used to 
improve analysis[5, 17]. There are at least three distinct styles of electronically supported meetings that blend 
different amounts of electronic and verbal interaction and facilitator intervention: chauffeured (participants interact 
verbally), supported (participants interact verbally and electronically), and interactive (participants interact 
electronically)[17]. 

Field studies using the EMS technology have reported significant reductions in the time required to complete 
projects (e.g., more than 50 percent reported in [17]). Laboratory studies have found it to be particularly useful for 
creativity tasks where teams are asked to generate new ideas (a fourfold increase in the number of high-quality 
ideas:[6]). 

STEPS IN THE ENTERPRISE ANALYZER APPROACH 
PREPARATION 

Our approach includes four basic steps (see Table 1). The first step is preparation. In this step, the objective is to 
establish a climate for change within the organization. Both senior management and the line employees must 
understand the need for change and be committed to making the change. 

Whenever no single person understands the whole system, it becomes important to build a cross-functional team 
that includes representatives from all functions within the business system to be re-engineered[9]. The key 
stakeholders from organizations that are suppliers or customers of the system should be included in the 
re-engineering team as they may have insights unavailable to those within the system. The objectives and scope of 
the project must be clear so that those assigned to the teams understand their mission. 

ENTERPRISE MODELING 

The objective of the second step, enterprise modeling, is for all members to gain an understanding of the current 
processes, since stakeholders may have conflicting assumptions in their views of the operations. First, team 
members identify and clarify the overall problems and issues, the goals, mission, and critical success factors of the 
enterprise, and the fundamental assumptions about how the enterprise should function. It is important to discuss 
and come to consensus on pivotal issues. Next, the team develops a process model that reflects what is currently 
done, who does it, and what information is shared among the processes. Documenting the current situation, via 
building a model of the business system, is a challenging and nontrivial exercise. The objective of model building is 
as much to help participants learn how the current system actually works as it is to produce a complete model. 

REDESIGN 

The essence of re-engineering is changing (1) what gets done, (2) who does it, and (3) what information is 
exchanged among processes, people, and organizations. Each of these three questions may identify potential 
re-engineering opportunities. Thus, the third step is redesign in order to find a set of radical improvements. Both 
"soft" and "hard" thinking (as defined by von Oech[22]) are used to develop a set of proposals for change because 
they are complementary; they encourage different types of ideas. 

The objective of soft thinking is to encourage individuals to generate unconventional ideas. Soft thinking is fuzzy, 
ambiguous, playful, paradoxical, and not logical. It involves lateral thinking, approaching the issues from new and 
unusual directions. Von Oech[21 , 22] provides many soft thinking techniques, two of which we have adapted for 
re-engineering: metaphorical thinking and what-if games. Metaphorical thinking asks participants to describe the 
current and desired state of the business system using figures of speech (e.g., "The company is like a jumping bean 
on a hot skillet"), while what-if games ask participants to challenge basic assumptions about the business. We use a 
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series of exercises and rules designed to promote soft thinking solutions to find sinnilarities, patterns, and 
connections among apparently unrelated things. 

Formal analysis techniques, while useful, are not designed to promote creativity. They are "hard" thinking as defined 
by von Oech[221: logical, reasonable, focused, analytical, and based in reality. With this approach, we provide a 
series of formal analysis techniques and rules designed to identify inefficiencies in the current process flow. 
Formally modeling and analyzing the processes, people's involvements, and information flows are one aspect of 
re-engineering. Can processes be improved, eliminated, or off-loaded to someone else? Can we reduce the 
number of people involved with a process, the number of processes a person performs, or the number of 
organizations for whom the person performs a process? Can we reduce the information flows by combining 
processes or reassigning job responsibilities? After a large set of ideas has been generated, the next step is to 
organize, filter, and select ideas that will be refined into specific change proposals. 

IMPLEMENTATION 

The fourth and final step is implementation. A set of proposals is selected for immediate implementation, thus 
triggering actions to introduce changes and monitor the results. Re-engineering proposals may be quite radical and 
not unequivocally destined for success, particularly if the people who must implement them lack critical skills, 
aptitudes, and/or knowledge. While it is difficult to phase in radical change gradually[7], the redesigned processes 
can, and should, be prototyped. A small pilot project should be used to test the ideas before the company commits 
on a grand scale. 

ENTERPRISE ANALYZER ARCHITECTURE 

Our approach involves the blending of human and technical resources. The first is the client's re-engineering team, 
typically ranging from 8 to 20 people, drawn from all levels of the organization, as well as members from outside 
organizations. 

The second resource is an analyst team responsible for assisting, coaching, and supporting the re-engineering 
team during the project. This team includes a facilitator as well as a technical support person. The facilitator is 
responsible for training participants on the re-engineering process, and guiding the team through use of the 
automated tools. Technical support is responsible for maintaining the software, operating some of the tools, and 
providing additional assistance as required. 

The third resource is an electronic meeting room that enables the teams to use automated support. This facility 
provides a computer workstation to each team member to permit anonymous electronic communication among 
team members and to enable each member to work in parallel on the task. The room also provides a large screen 
video projection system so that team members can also use the computer system as an electronic blackboard to 
support verbal discussion of key issues. 

The fourth resource is the knowledge repository used to store the enterprise model and the software to build and 
maintain it. The general structure of the Enterprise Analyzer software architecture can be described with a series of 
concentric circles and arcs. At the core of the architecture is the repository. The Model Object Editor, Queries, and 
Reports interact directly with the repository. The Translation Utilities function as Application Program Interfaces for 
the GroupSystems' tools and the other tools that have been created to support Enterprise Analyzer. We describe 
the software components below. 

REPOSITORY 

The centralized repository follows the AD/Cycle approach; it adds some object-oriented features to an entity 
relationship model[14, 15]. Basic tenets of our methodology imposed three principal requirements for the design of 
the repository. First, the client organization must be able to create its own metamodel, such as defining a 
requirements language. Second, all participants must have concurrent access to the data in the repository. Third, 
the repository must have a means to easily import and export data to and from existing computerized systems, 
previous reports, studies, system documentation, and work done by participants between sessions[18]. 

We chose commercial database software to implement the repository since a CASE tool was unlikely to meet all of 
our requirements. Commercial CASE tools typically use a project dictionary to store process models via a 
combination of unstructured narratives and a predefined structure. Furthermore, few CASE tools allow user groups 
to have concurrent access to the repository, or provide an easy import/export facility. 
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The basic metamodel includes entities such as processes, goals, and relationships but can be extended to include 
any entities, attributes, and relationships that are specific to the organization. The repository starts with a simple set 
of metadata, such as the dictionary, then lists all of the Entity-Relationship-Entity combinations that are valid, and 
catalogs information that defines the menus, directories, and programs used to maintain the entity and relationship 
instance records. For example, the catalog would include the model object editor program name used to update a 
process description, or a report program used to generate a specific completeness and consistency report. Entity 
records describe individual entity instances and their attributes. Relationship records will document or describe the 
relationship between two entity instances and are either implicit or explicit. Implicit relationships are derived by 
programs to minimize any redundant or repetitive work that would make poor use of the participants' time during the 
meeting. Whenever entities are described with a hierarchical numbering scheme, EA automatically generates 
relationship records, for example, process 3.2.1 can be assumed to be a decomposition of process 3.2. The group 
can also enter relationships explicitly by using the Enterprise Matrix or a model object editor program. 

MODEL OBJECT EDITOR 

One of the first activities after the metamodel has been defined is to create an editor program for each object type 
defined in the model. This editor program is used by the participants to add and update records defining specific 
instances of the object type, such as process "3.2.1 ." Participants can also quickly view a list of the processes that 
are already defined so they add fewer redundant process descriptions. Participants are also able to navigate 
through the model from object type to object type. For example, if the client team feels that it is helpful to examine 
processes and job descriptions alternately, a menu option can be added to the object editor programs for processes 
which allows the participant to switch to job descriptions and vice versa. 

TRANSLATION UTILITIES 

Translation utilities allow data sharing between the repository and the other software (e.g., GroupSystems) used in 
the project, When information is gathered using GroupSystems tools, such as Idea Organizer, the same tool may 
be used to gather goals, critical success factors, high-level processes, or any other type of object. Each object type 
may be defined in the repository's metamodel differently. The translation utilities are used to convert the standard 
output from the tool into a format that can be read by the repository's data import program. As a result there might 
be three different translation utilities that all take input from Idea Organizer and create output for a different object 
type defined in the repository. 

In addition, these utilities afford the opportunity to append audit information such as the date, time, location, group, 
or meeting number. Most translations required to generate output from the repository can be done with the 
repository's query language and saved as a report program for repeated execution and/or customization. 

GROUPSYSTEMS TOOLKIT 

GroupSystems is an example of an EMS designed to support large group meeting at the same time in the same 
location. Each GroupSystems tool was initially designed to support one of four types of group activity. The first 
category, idea generation and brainstorming, involves the development and exploration of issues relevant to the 
task. The second category, idea organization, involves synthesizing, structuring, and organizing ideas into specific 
alternatives, which may follow the generation of ideas; if a group has previously discussed an issue, a meeting may 
begin with idea organization without idea generation. Tools in the third category, prioritizing, support the individual 
members in evaluating alternatives. The final category contains special-purpose tools that provide formal 
methodologies to support policy development and evaluation (e.g., stakeholder analysis), and a group text editing 
tool. See Nunamaker et al.[17] for a description of the GroupSystems tools. 

ENTERPRISE MATRIX 

Enterprise Matrix (EM) represents a family of matrix tools designed to allow a group, working in parallel, to establish 
the relationships between any two sets of objects (see figure 1)[8]. (Figure 1 omitted) One use of EM might be to 
establish the relationships among processes and organizations. In this case, Enterprise Matrix uses, as input, the 
process names as one axis of the matrix and organization names as the other axis. The list of allowable values for 
the relationship between a process instance and an organization instance is defined by the project leader and 
refined by the group. The relationship is represented by the value of a cell (the intersection of a row and a column). 

GRAPHICAL BROWSER 
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The Graphical Browser (GB) can use any relationship records kept in the repository to display portions of the model 
graphically[20]. It is typically used to generate graphical displays of the data gathered using Enterprise Matrix. The 
resulting drawing can be a structure that is as simple as a tree or as complex as a network structure. Users can view 
the descriptions that exist in the repository for any particular object by moving the cursor over the object and 
selecting "description" from a menu. GB also isolates orphan nodes, to help analyze the model for completeness. 
The relationship labels may be optionally displayed on the connecting arcs. The user can "zoom out" to see the 
entire structure of the network, or zoom in to concentrate on a portion of the drawing. Drawings can be linked 
together to let the user jump from a "parent" drawing to "child" drawings and back. A single process is exploded into 
a tree of subprocesses in the child drawing. GB is used to display objects and relationships already in the model. 

CASE STUDY 

This section presents the results of using the EA approach with one organization. We preface the case description 
with the basic research design and some background on the organization. 

RESEARCH DESIGN 

The research design follows the system development research methodology advocated by Nunamaker et al.[6]. 
This approach holds that systems development is an evolutionary process and the experiences of developing and 
evaluating the system often lead to further enhancements to the system. The tools in EA were designed and 
implemented as a phase within this research methodology. The system was then used in the pilot project to support 
procedures developed by the researchers. A case study was used to evaluate both the system and the Enterprise 
Analyzer methodology. 

To develop a well-rounded perspective of the case, data were collected from six sources to build a chain of 
evidence and to permit triangulation over methods and time. Given the nature of research questions and the use of 
a case study methodology, most of the data sources were qualitative. First, the behavior and actions of the group 
members were observed and recorded by at least one researcher during the meetings. Second, system logs 
recorded all keystrokes at all workstations, providing complete transcripts of all electronic comments made during 
the meetings. Third, questionnaires were completed anonymously by participants at the end of the study. The 
questionnaire Items focused on evaluating the methodology and the tools used to support the methodology. Fourth, 
participants' opinions on a range of open-ended questions were sun/eyed during the middle of the study and at the 
end. Fifth, extensive interviews were conducted with the project leaders during the project and after It concluded. 
These interviews continued several months after the project (i.e., after the organizations had begun using the results 
from the re-engineering effort) in order to gain a sense of the lasting impacts. The interviews attempted to get 
participants to describe "what worked and what didn't work?" by reflecting on different aspects of the project and 
explaining how it differed from previous attempts to improve quality. Finally, the technical report was extensively 
reviewed by five participants to ensure Its accuracy. 

ORGANIZATION BACKGROUND 

The organization under study was a large multinational firm. The area selected for re-engineering was at the very 
heart of the organization: the corporate accounting process for all of the United States. This process included 33 
application systems responsible for internal business functions such as client billing, inventory, sales commissions, 
and so forth. All (approximately 1 ,000) of the firm's U.S. branches depended on at least some of the information 
processed at the data center. Each business unit developed and maintained its own applications and then 
contracted with the data processing center to actually run the applications on a day-to-day basis. 

The activity was an ideal candidate for re-engineering. Most of the business processes and supporting software had 
been originally developed in the early 1960s and had gradually grown as business requirements and technology 
changed. The processes and software were no longer being used as originally intended and designed, but had 
undergone a long series of uncoordinated, incremental improvements. No clear overall process design had been 
undertaken in 25 years and many of the original constraints had been overcome with technology-so this project 
might better be termed process engineering rather than re-engineering. Although databases were developed, they 
were merely conversions of the earlier flat file structures. 

The center had two types of software: the interactive "real-time" database update programs and the "batch" 
programs. All programs ran under Advanced Administrative System (AAS), an assembly language-based product 
originally developed in 1 960s that prevents real-time and batch jobs from being executed at the same time. Thus, 
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the data center operated in two modes, providing real-time access for all branch offices and sales/service staff in 
the United States during normal business hours and running batch reconciliation jobs during the night and on 
weekends. Approximately 27,000 jobs were run per month across the 33 applications. Although the hardware was 
continuously upgraded to state of the art, the software and procedures were not. 

In the year prior to this study, the center launched a major initiative to improve quality in this process; the objective 
was to reduce the number of processing errors to a defect rate of Six Sigma (successful completion rate of 99.9997 
percent)[10, 1 1]. After several months of error analysis and planning, new operating procedures were introduced. 
The successful completion rate steadily increased until it reached a plateau at 99.96 percent-or just over three 
Sigma. While this was impressive, it was still more than 1 00 times the target error rate. The center decided that, to 
achieve the target error rate, it had to radically redesign its business processes. 

Our re-engineering effort quickly focused on one 40-person unit within the center, Application Support (AS). The AS 
group was the intermediary between the application owner and the operations group that actually executed the jobs 
within each application system. The major responsibilities of AS included scheduling and rescheduling jobs, 
verifying that jobs ran successfully, and solving problems that occur. Since the applications included customer 
billing, commissions, and so on, there was strong pressure for verification of transaction control totals. Many of the 
functions that the AS staff performed were designed to provide audit information. Standard operating procedures 
were sufficiently complicated that there was some suspicion that these reconciliation steps might be causing more 
problems than they prevented. 

PROJECT ACTIVITIES 

In this section we describe the pilot project with AS in terms of the phases outiined in the Enterprise Analyzer 
Methodology. Figure 2 displays the timeline of the meetings and phases of the project. (Figure 2 omitted) 

PHASE 1: PREPARATION 

A planning meeting with leaders from the data center was used to elucidate the goals of the project and the types of 
objects (entities) that should be included in the model. Each object type was then defined in the repository with as 
many validation and index requirements as seemed useful. One application was selected to focus the discussions 
and all modeling was done from that application's perspective. Participants included those AS staff members 
involved in any way with that application, as well as managers from affected organizations including the application 
owner. 

The prototyping features of the repository platform were used to create template model editor programs, including 
data entry screens, for generic object types such as processes, data elements, and relationships. The model object 
editor programs were then customized from our template programs to capture the terminology and information 
needed by AS. 

PHASE 2: ENTERPRISE MODELING 

The first step was to identify current problems and critical success factors (CSFs) (the AS mission was clearly stated 
in an initial briefing), and AS management viewed assumptions and constraints as superfluous. GroupSystems tools 
were used for both steps. Participants first brainstormed using an interactive process solely electronic 
communication) to address the question, "What are the key problems and issues that you face on a day-to-day 
basis (including weekend, month-end, and year-end processes?" Then the GroupSystems Idea Organizer (lO) tool 
was run in a chauffeured mode to consolidate these problems into a narrow set of CSFs that could be used to 
gauge the success of any modifications resulting from our sessions. The group settled on ten CSFs that were 
rank-ordered by importance. 

The second and most substantial step was creating the process model. The first step was identifying the high-level 
processes that characterize the application being studied. This was accomplished by using 10 in a chauffeured 
mode. Each process was classified as either "as required" or "routine." Within those two classifications, the group 
generated four and six processes, respectively. 

The group of 15 participants was then divided into four subgroups of three or four participants, based on area(s) of 
the participant's previous experience, with each subgroup assigned specific processes to describe and decompose. 
The session leader first led the entire group through the definition and decomposition of one of the high-level 
processes, before letting the subgroups work independently on process decomposition, to improve the likelihood 
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that ail subgroups would work in a consistent manner. Deciding how far to decompose processes is difficult. Our 
guideline was that they should decompose a process until they began duplicating existing documentation. The focus 
was on "what" processes did, not the exact details of "how" they did it. 

The subgroups worked for about two hours before the session leader called them together to validate one of the 
decomposed processes. Although many attributes had been interpreted consistently among the subgroups, the 
"owner" attribute of a process was interpreted differently by two subgroups. Also, some subgroups decomposed 
processes in much greater detail than others. Following the discussion, the group again broke into subgroups to 
refine areas to be more consistent with the general interpretation of the meaning of the process attribute and to 
complete the decomposition of their assigned processes. This cycle of (1) subgroup assignment (2) group tutoring, 
(3) subgroup work, (4) group review, and (5) subgroup refinement and subgroup work improved the consistent use 
of terminology and methods among each of the subgroups. 

The other entities in the enterprise model were organizations and applications. Organizations are recognized areas 
of responsibility (e.g., service level management). The list of 33 applications that make up Application Support was 
supplied by one of the project leaders, then reviewed and consolidated by the group. 

Enterprise Matrix was used to establish the relationships among people or organizations and processes in a 
responsibility matrix. The available relationships (all mutually exclusive) were (1) primary responsibility, (2) 
supporting role, (3) exceptional involvement, and (4) other. The project leader described the terminology, then the 
session leader worked through one complete column with the group as a unit to improve the consistent use of 
terminology after the group was divided into subgroups. The session leader navigated each cell of the matrix to 
review the responsibility matrix, creating a relatively tedious process since the group had spent the training period 
together and used the terminology consistently. 

A second matrix modeling the information flows among processes and processes/organizations/applications was 
then completed. Unlike the first matrix, the relationships in the information flow matrix were not mutually exclusive: 
(1) sends data to,(2) sends control to, (3) sends status to, (4) receives data from, (5) receives control from, and (6) 
receives status from. After all the subgroups completed their assigned sections, a group review of the information 
revealed that all of the subgroups had not interpreted the terminology in a consistent manner. After spending some 
time trying to resolve conflicts, the group agreed that the project leader could review the remainder after the 
meeting. 

PHASE 3: REDESIGN 

The creative stage consisted of three steps in which the group used a combination of GroupSystems tools (mostly 
the brainstorming tool called Topic Commenter) for "soft" thinking, "hard" thinking, and proposal filtering. 

We began with soft thinking, with the objective of having participants think about familiar things in an unconventional 
manner. The first step was developing metaphors to describe how application support would be described today, 
and how it could be in ideal circumstances. The rest of the soft thinking step used what-if games and breaking 
assumptions (see Table 2). 

The next step was hard thinking. The group was provided with the process model in three formats (text, matrix, and 
graphical). All members first identified ways to eliminate each and every process, and the benefits that would occur 
from doing so. No process was to be spared, and every member had to provide at least one idea; the objective was 
to require all participants to generate ideas to meet the needs. Next, they identified ways to reduce the number of 
people involved in each process in order to achieve better levels of coupling and cohesion for the processes. The 
participants identified candidates for eliminating involvement with potentially high payoffs and proposed ways of 
eliminating them. Finally, participants identified ways to eliminate information flows. 

These two steps resulted in more than 50 single-spaced pages of ideas. The final step was to organize and filter the 
ideas into a set of specific proposals for change. Using 10 and then a group writing tool, the group produced a set of 
proposals summarized in Table 3. This step proved crucial in the overall project. Many of what the research team 
considered radical ideas were eliminated in this filtering step (e.g., eliminating legal contracts between the firm's 
own departments, letting the "customer" department play a larger role in prioritizing and scheduling applications). 
Some of these ideas were never proposed to become part of the change proposal, but others were raised by some 
member(s) of the group. During group discussion, senior members of the group objected to their inclusion, saying 
they were not "practical" or would "never be accepted" by more senior managers. 
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PHASE 4: IMPLEMENTATION 



Shortly after the project meetings were completed, the data center was involved in a large-scale strategic 
reorganization. The data center is no longer part of the company, but is now part of a subsidiary. Since many of the 
assumptions behind the proposals were no longer valid, the project was suspended before any of the proposals 
could be implemented. 

ANALYSIS 

PROJECT EVALUATION 

The evaluation of the methodology, tools, and ideas proposed is based on data from a variety of sources, including 
observation, questionnaires, debriefing of participants using the EMS, and interviews. 

ENTERPRISE ANALYZER METHODOLOGY 

Table 4 summarizes questionnaire results evaluating the methodology. (Table 4 omitted) Overall, participants rated 
the methodology as being effective, efficient, and satisfying. The participants rated the effectiveness of the 
methodology at generating ideas particularly highly. 

The participants comments supported the questionnaire results. For example: 

The DSC [Decision Support Center, the EMS meeting room] allowed a free and uninhibited flow of information....! 
think we got a lot of information that we normally wouldn't have if this were done during a [regular] meeting." 

And: 

The automated on-line tools were a great improvement over hand written methods of gathering brainstorming data. 

The participants' only area of concern with the methodology itself was the amount of their time required, which was 
exacerbated by the need to perform regular business tasks throughout the meeting days: 

The quality of meetings was enhanced. However, I think a hindrance to the quality maybe the length of time it took 
to get us to this point. 

And: 

With running the business the primary focus, many people couldn't/didn't attend. 

Their input could have been quite valuable. 

And: 

Maybe we should have been away from the office....Too many interactions, too many other things due. 

One measure of output is the number of pages of documentation or ideas. Another measure for the idea generation 
activities is the number of proposals generated by the activity. These proposals were analyzed by the center's 
project leader to establish the phase in which the idea was conceived. Many of the final 15 proposals (see Table 3) 
evolved throughout several activities and thus they can be attributed to several activities. For example, one part of 
the proposal may have come from the "What If Games" while another part came from the Information Flow Analysis 
and thus can be counted in both places. An analysis of the results show that a majority of the ideas were conceived 
during the "hard" phase. 

TOOLS 

Table 5 summarizes questionnaire responses to questions concerning how well participants perceived each tool to 
fit the methodology. In general, the tools were very well received and thought to be effective. While all tools received 
positive evaluations, the new tools developed specially for the EA process (Model Object Editor, Enterprise Matrix 
Group Writer) received lower ratings than did the standard GroupSystems tools (Electronic Brainstorming, Topic ' 
Commenter, Idea Organizer). There are at least two plausible explanations. First, these were new "Beta test" tools; 
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the partidpants encountered several bugs and the user interfaces were not yet consistent with the other tools. 
Second, the tools and the activities they supported required the participants to spend more time learning than the 
standard DSC tools with which they were familiar: "Learning new software slowed the process some." If participants 
were less comfortable with the tools, they may have rated them lower. 

PROPOSALS 

In general, participants perceived the proposals to be effective and were satisfied with them. Participants also noted 
that participation in the project promoted organization learning. The questionnaire results suggest that participants 
gained a greater understanding of Application Support. Interviews support this conclusion and suggest that 
participants also gained knowledge of other areas vi«th the company: "I became aware of the people that are my * 
peers through this project. It gave me more insight into what motivates the people that I interact with on a day to day 
basis." 

The goal of re-engineering is to find radical ideas. However, the list of proposals produced by the group had a 
mixture of both radical and incremental improvement ideas, with about twice as many incremental as radical ideas. 
Interviews with the project manager and the manager's subordinates suggested that the incremental ideas on the 
list were not "new" per se. They had either been proposed during the previous improvement efforts (and either 
turned down or postponed due to their expense) or had recently come up in casual discussions (but had not been 
widely discussed or formally proposed). 

The data center manager was rather disappointed with the list of proposals for two reasons. First, he commented 
that many ideas were not new or radical, but were previously proposed incremental ideas that had originally been 
turned down. The manager's second concern was that many of the new, radical ideas were too expensive or too 
risky to implement. They were, in essence, too radical. 

Why were the ideas proposed mostly "old" incremental ideas? One interpretation is that despite the creativity 
techniques used, the group failed to generate new radical ideas, but instead simply restated existing ideas. The 
project manager and the research team formally examined the meeting transcripts in detail to seek evidence to 
support this interpretation. We found none. 

Many unusual, new, radical ideas were in fact generated. They simply did not pass the filtering step and make it into 
the final set of proposals. During the proposal filtering stage, many ideas were explicitly rejected by the participants 
as being too radical, too costly, or outside the scope of the project. We believe two forces were at work. 

First, we believe that group members were unsure of the scope of the project and the commitment of senior 
managers to radical change. Despite senior managers' statements asking for radical ideas, we believe that 
participants were not fully convinced. The senior members of the project group chose to err on the conservative 
side by selecting less radical, more incremental ideas. Rather than take a risk and propose very innovative ideas 
they tned to steer a safer course-one that backfired, since senior management really did want radical ideas. 

Second, we believe that the middle managers that formed the core of the re-engineering team lacked the vision of 
senior management, who might have been better able to propose radical ideas cutting across organizational 
boundanes. These participants were more likely to view current policies and interorganizational relationships as 
fixed constraints that could not be really changed. While they were able to relax these constraints during 
brainstorming and the creativity exercises, they were unable to truly believe that these constraints could be broken 
and thus filtered out the more radical ideas as they were drafting their proposals for action. 

IIVIPROVING THE METHODOLOGY 

Intervievi/s with participants and our analysis indicated at least five areas for improvement. First and foremost more 
time and effort must be devoted by senior managers. It is essential to actively communicate the nature of the 
organizational commitment to the re-engineering team and present a clear and common understanding of the 
scope of the project. This was done at the start of the project by the project leader, a middle-level manager but this 
proved insufficient. We believe that participants were unsure of senior management commitment, and thus many 
radical ideas were filtered out. Had the scope and commitment been defined, and actively and enthusiastically 
communicated by the executive sponsor, the data center manager, and had this manager and other senior 
managers actively participated in the project, the results might have been different. If they had been active 
participants, the more radical ideas might not have been filtered out, and the senior managers might have had a 
better understanding of the rationale behind some of the more expensive and risky radical ideas and been more 
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Second, the desired level of process decomposition needs to be defined very clearly at the beginning of the 
enterprise modeling phase. It has been argued that the primary benefit of the process model is the knowledge 
gained in building it, not the model itself[7]. We encouraged participants to focus on the "what" of the model (broad 
general statements), not the "how" (detailed step-by-step descriptions). However, the participants still attempted to 
provide very detailed descriptions with every single exception documented. Even with continued reminders that the 
model was going to be discarded, participants still found it extremely difficult to accept a less than perfectly 
complete model. 

Third, the entire group reviewed the work done in the subgroups to identify inconsistencies in definitions and 
assumptions, as well as content. Despite several examples, and general agreement, on terms, subgroups did adopt 
different interpretations. This suggests that the progress of the group during each session needs to be monitored 
periodically to ensure that the group is working towards the same goal. We suggest an "expert f!oater,"-a person 
who circulates among the teams and ensures that each team has a consistent understanding of the task goals and 
terminology. 

Fourth, this review of processes and relations by the entire group took a substantial amount of project time. Much of 
it was spent correcting or accommodating minor differences in opinions or special cases, which in retrospect added 
little. Again it proved extremely difficult to have the group accept a model with minor inconsistencies. This process 
was essentially verbal, and thus very time-consuming. We propose that an alternative work room, such as a project 
office, which has a few workstations to access the EA model can allow participants to review the information at their 
convenience and their own pace. Such support would allow the group to concentrate on activities that require the 
interaction among the meeting participants during the time spent at the DSC. 

Finally, a formal process for evaluating the group's proposals is needed. This should include a complete 
stakeholder analysis aimed at evaluating the proposals to determine the support needed from management and 
other applications. Also, a model of the re-engineered process needs to be built so that the group can evaluate the 
impact of the proposed changes in the organization. 

CONCLUSION 

We believe that this pilot project was a success from a research perspective. The project demonstrated that the EA 
tools and methodology were extensible and flexible, and could be used to support re-engineering of a business 
process at the very core of a large multinational firm, a process that had been extensively improved using TQM 
techniques before the project was undertaken. 

The project's value to the organization is less clear. Participants gained a better understanding of the structure of 
the process and produced fifteen proposals for change. While the proposals were potentially valuable, they were 
not implemented, due in part to the major reorganization and in part to the participants' unwillingness to propose 
radical changes to senior management. Ironically, if this area had not been part of the first wave of reorganization, 
the participants might have been encouraged by sweeping changes elsewhere in the organization. One might say 
the project was a success that failed. 

TABLE 1 THE ENTERPRISE ANALYZER PROCESS 

1 . Preparation 

1.1. Establish climate for change 

1 .2. Develop the vision 

* Set project scope and goals 

* Establish commitment 

* Staff the teams 

1 .3. Meta Modeling 
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* Define enterprise model objects 

* Define possible relationships 

2. Enterprise Modeling 

2.1 . Define enterprise goals and constraints 

* Identify current problems and issues 

* Identify mission and critical success factors 

* Identify fundamental assumptions and constraints 

2.2. Create process model 

* Define business processes 

* Define people/organizations' involvement with processes 

" Define information flows among people/organizations and processes 

3. Redesign 

3.1. Free-form creative ("Soft") Thinking 

* Metaphorical Thinking 

* What-if games 

* Breaking fundamental assumptions 

3.2. Rational analytic ("Hard") Analytical Thinking 

* Eliminating processes 

* Reducing involvements 

* Cutting information flows 

3.3. Develop proposals for change 

* Organize and filter ideas 

* Rank and select ideas 

* Refine ideas into proposals 

4. Implementation 

4.1 . Select proposals for immediate action 

4.2. Pilot test and evaluate 
TABLE 2 SOFT THINKING 
1. Metaphorical Thinking 

a. Make metaphors of the situation today 
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b. Make metaphors of the desired situation 

c. What is the ideal system 
2. What-lf Games 

The objective of What-lf Games is to challenge the basic assumptions held about the business and how it should be 
conducted. These are examples from the Application Support Case 

a. What if Application Support had three people? 

b. What if Application Support had 300 people? 

c. What if batch processing took 1 0 seconds? 

d. What if batch processing took two days? 

e. What if batch processing was done during the day? 

f. What if batch processing was never run? 

g. What if batch processing never ran without error? 

h. What if we could predict each job's outcome? 

i. What if everyone could do everyone else's job? 
j. What if fixing all errors took 10 seconds? 

k. What if there never were any errors? 

I. What if everyone did their job perfectly? 

m. What if Application Support was paid based on the error rate? 

n. What if all processing was done in real time? 

TABLE 3 SUMMARY OF PROPOSALS 

1 . Increase Automatic Balancing of Jobs 

2. Career Path Changes and Function Realignment 

3. Simplify Management structure 

4. "Real Time" available almost 24 hours/day 

5. Maintain Shadow Sites for Fast Disaster Recovery and Continuous Availability 

6. Simplify Price Update Mechanism 

7. Automated Problem Determination and Recovery Management 

8. Wideband Data Transmission Enhancements 

9. Automate JCL Maintenance Requests 

10. Evolution of Service Level Management 

1 1 . Make Security (RACF) an Owner Responsibility 
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12. Automate Job Setup and Scheduling 

13. Status Report Enhancements 

14. Revise Meetings 

15. ATRS Enhancements 
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